Dynomotion

Group: DynoMotion Message: 9556 From: par.hansson80 Date: 5/27/2014
Subject: Mac/Linux port of KMotion software and Java binding.

Hi Tom


First of all thank you for a great product. The reason a choose the KFlop for my CNC mill is the open source software. I'm a systems developer and find it a lot easier to design software than hardware. Although Windows is not my preferred platform of choice. My first idea was to port the software to run on Raspberry Pi and develop a GUI using Java (or some other language) for the GUI parts. However during my work i have come to understand how much logic the GUI is actually contains. Maybe I'll just settle with a simple GUI and use the original KMotionCNC or Mach3 for a while, and let others to that part.


Currently my progress so far is that i have ported KMotionServer KMotionDLL and GCodeInterpreter to run on MacOS X and have also done some testing on Raspberry Pi with good results. Also I have developed JNI bindings for KMotionDLL API and parts of the GCodeInterpreter to execute from Java program all working with callbacks. I have tried to keep original code unchanged for minimize changes needed when an update is released. Surprisingly small changes in the code is needed to make this work. 


The thing I have struggled the most with is TCC compiler. I used the latest release of tcc, version 0.9.26.  

Fixing a broken cross-compiler was a tough task. But my hair is still not gray. The only thing is, in KMotion the c code is compiled with -g flag, generating debug binaries. And heres my question. Is this really necessary? Because i have not solved a problem with section address alignment when i add the -g flag. Without that my binaries are the same as when compiled on windows without -g flag. 


Best Regards Pär Hansson
Group: DynoMotion Message: 9561 From: Tom Kerekes Date: 5/27/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Pär Hansson,

That sounds pretty amazing.  We are very interested in the Linux Port of the KMotion Libraries.  Do you plan on releasing this publicly?  Anything we can do to encourage you to do so?  We were looking at doing that but there are so many issues with inter-process communication, Threads, Mutexes, File Access, Strings, USB, Messages Boxes, etc...   We have been able to get it running under Wine (even Mach3) but that doesn't feel very stable.

Regarding TCC67 Compiler.  I'm surprised that is a difficult issue because that should be all just isolated (OS independent) C code with a file in and a file out.  However we branched from the community TCC base many years ago.  I follow the TCC community base and realize they have made tremendous improvements that could be of great value.  But things are so different I suspect a merge would be very difficult.  I doubt it they have many of our C67 related fixes.  You might consider using our Branch instead.  I do know we made the mistake of using CStrings rather than STL Strings so that would need to be changed.  But to answer your question:  no the debug -g flag should not be required.  However the debug info is very helpful in debugging the TCC67 compiler when there is an issue.  It allows the .out file to be opened in Texas Instruments Code Composer Studio and symbolically see mixed C and assembly.  But normal Users would never do this.

Regards
TK

Group: DynoMotion Message: 9568 From: par.hansson80 Date: 5/28/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Tom

I'm glad to hear that you are interested. And I'll be happy to share. I need to do some more work(missing features and cleaning) and then I can post the code or invite you to my git repository. All the things you mention has been quite a struggle for me too since i don't use much C or C++ in my daily work. None to be specific (Java developer).  But it has been interesting and I learned a lot.  

The CMutex really is a beast :) . In C++ 11 there is a type recursive_timed_mutex that almost does the trick. I currently don't have the same support for multiple processes using the same KMotionServer To be honest I have not tested that yet. It might work though. However, shared libraries are not handled exactly the same way as sharing a windows DLL (guessing). I think that part can be solved further on if necessary.

For the CString I started to write a wrapper class with all the methods used. But then I stumbled over an existing CString port that has all the CString features. Although it would be even better to removed that dependency. Rome was not built in one day. File access and threads was not a very big deal. A wrapper class instead of the CFile made code changes obsolete. MessageBoxes not solved yet (I just print messages to console). But a good way would be to hide this dependency behind a callback just as the other callbacks. 

The TCC should'n be a big problem as you say. I tried a few times but no luck. And then i downloaded the latest version to start with something that compiles. I patched the code with almost all the patches from your version. Lots of code was moved and rewritten. I found some bugs (at least I consider them to be) by comparing assembly output and reading hex code. The Texas Instruments Code Composer Studio might have helped me. But too late :)

Regards Pär
 
Group: DynoMotion Message: 9569 From: Tom Kerekes Date: 5/28/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi  Pär,

Yes we are very interested  Please share as soon as possible.  If your code (and instructions) are sufficient that we are able to do something simple like KMotionDLL.WriteLine("ClearBit46"); on a Linux box (I'd prefer to start with a PC) we would be happy to provide a token of our appreciation of 4 free KFLOPSs.

I enjoyed the description of your progress (especially the "Rome was not built in a day").

Regards
TK


On Wed, May 28, 2014 at 1:58 PM, par.hansson@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi Tom


I'm glad to hear that you are interested. And I'll be happy to share. I need to do some more work(missing features and cleaning) and then I can post the code or invite you to my git repository. All the things you mention has been quite a struggle for me too since i don't use much C or C++ in my daily work. None to be specific (Java developer).  But it has been interesting and I learned a lot.  

The CMutex really is a beast :) . In C++ 11 there is a type recursive_timed_mutex that almost does the trick. I currently don't have the same support for multiple processes using the same KMotionServer To be honest I have not tested that yet. It might work though. However, shared libraries are not handled exactly the same way as sharing a windows DLL (guessing). I think that part can be solved further on if necessary.

For the CString I started to write a wrapper class with all the methods used. But then I stumbled over an existing CString port that has all the CString features. Although it would be even better to removed that dependency. Rome was not built in one day. File access and threads was not a very big deal. A wrapper class instead of the CFile made code changes obsolete. MessageBoxes not solved yet (I just print messages to console). But a good way would be to hide this dependency behind a callback just as the other callbacks. 

The TCC should'n be a big problem as you say. I tried a few times but no luck. And then i downloaded the latest version to start with something that compiles. I patched the code with almost all the patches from your version. Lots of code was moved and rewritten. I found some bugs (at least I consider them to be) by comparing assembly output and reading hex code. The Texas Instruments Code Composer Studio might have helped me. But too late :)

Regards Pär
 
Group: DynoMotion Message: 9570 From: ericncn Date: 5/28/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Just want to let you know that there are users (like me) that are very interested in the Linux port too.

Very long time ago I was a computer person and I wrote some multiprocessor parallel  code under Linux using mutex & stuff but honestly so many years has passed I've forgot everything hence I can't help on this.

Even though, I think I could revise my OpenGL quite easily.  In case porting the viewer under Linux is a problem (and if I find the time for it) I may be able to help with that...

Regards
EC

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Hi  Pär,

Yes we are very interested  Please share as soon as possible.  If your code (and instructions) are sufficient that we are able to do something simple like KMotionDLL.WriteLine("ClearBit46"); on a Linux box (I'd prefer to start with a PC) we would be happy to provide a token of our appreciation of 4 free KFLOPSs.

I enjoyed the description of your progress (especially the "Rome was not built in a day").

Regards
TK


On Wed, May 28, 2014 at 1:58 PM, par.hansson@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi Tom


I'm glad to hear that you are interested. And I'll be happy to share. I need to do some more work(missing features and cleaning) and then I can post the code or invite you to my git repository. All the things you mention has been quite a struggle for me too since i don't use much C or C++ in my daily work. None to be specific (Java developer).  But it has been interesting and I learned a lot.  

The CMutex really is a beast :) . In C++ 11 there is a type recursive_timed_mutex that almost does the trick. I currently don't have the same support for multiple processes using the same KMotionServer To be honest I have not tested that yet. It might work though. However, shared libraries are not handled exactly the same way as sharing a windows DLL (guessing). I think that part can be solved further on if necessary.

For the CString I started to write a wrapper class with all the methods used. But then I stumbled over an existing CString port that has all the CString features. Although it would be even better to removed that dependency. Rome was not built in one day. File access and threads was not a very big deal. A wrapper class instead of the CFile made code changes obsolete. MessageBoxes not solved yet (I just print messages to console). But a good way would be to hide this dependency behind a callback just as the other callbacks. 

The TCC should'n be a big problem as you say. I tried a few times but no luck. And then i downloaded the latest version to start with something that compiles. I patched the code with almost all the patches from your version. Lots of code was moved and rewritten. I found some bugs (at least I consider them to be) by comparing assembly output and reading hex code. The Texas Instruments Code Composer Studio might have helped me. But too late :)

Regards Pär
 
Group: DynoMotion Message: 9582 From: par.hansson80 Date: 5/29/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Tom

Wow! That is a really great offer. My current hacking exercises require me to remove my KFLOP from my CNC-machine, since i don't live in my workshop :) I have som future plans as well, building a laser cutter/engraver an developing direct print drivers using KFLOP as controller where an extra board might come on handy. 

I just started this evening, (It's night here now, I live in Sweden) setting up an new linux machine (latest Ubuntu) and composing installation instructions and scripts. All my work the last period has been done on MacOS X and it won't build on Linux for some reason. I'll probably have that fixed by sometime tomorrow.  I should be able to post something working this weekend.

You will be able to do a lot more than WriteLine commands. The GCodeInterpeter works as well. Even from within Java. But I still need to plead a saving clause "Works on my machine" :) 
And I have to be honest about what I have not testet yet. No motors connected so I haven't seen actual movement. Although the board responds plausible on the CheckDoneBuf commands and all the other stuff   the GCodeInterpreter does so I'll assume that it is all for real. Also I have not yet tested to download COFF-files. But according to my tests with logging it seems like it would work. I'm a little afraid of bricking my board if something goes wrong. Instead I let my setup program execute on thread 1 from flash on boot.


Regards Pär
Group: DynoMotion Message: 9583 From: par.hansson80 Date: 5/29/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi EC

Nice to hear that more people are interested in this. I'm currently not porting the GUI. But it won't be very useful without one so maybe I'll dive into that next. But I will most likely use Java for that. I'm thinking of using  eclipse as platform. I really like the idea of the pluggable design. Then others can write whatever plugins the want in a fairly high level language for different machine types and setups. 

I have made a very simple gcode editor showing what line is currently executed by the interpreter. But no 3D rendering yet :)

Regards Pär
Group: DynoMotion Message: 9586 From: Tom Kerekes Date: 5/30/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Pär,

That all sounds great.  I have an Ubuntu system that probably needs to be updated.  What Version are you planning to use?

Regards
TK

Group: DynoMotion Message: 9598 From: par.hansson80 Date: 6/1/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Tom

I downloaded the latest Ubuntu, version 14.04. The code builds on linux now, although I'm having trouble with  USB communication to the KFLOP. Since my Linux installation virtual and was last successful on Rasbian for Raspberry Pi, I set up a clean Rasbian but I have the same problem. Communication only works the first time I plug in the KFLOP and then I have to disconnect it to get it to work again. 

I have set up a some test code and the one problem is a timeout in KmotionIO.FlushInputBuffer when waiting for acknowledge for the sent abort character to DSP.  I have increased the timeout but that is not the problem. The first time it works ok. Restart program and it fails. The problem is intermittent but fails more often than it works. But almost works every first time after connect. I added FT_ResetDevice(ftHandle) after FT_OpenEx and it works a little better but not satisfying. When the FlushInputBuffer operation works i send a request DefineCS and the same problem occurs. Sometimes it works but most often it doesn't.  It seems to be some kind of driver problem. Windows, Linux and MacOS have their own drivers and both Windows and MacOS works so the problem is most likely in the Linux version or the underlying USB stack. 

Just wanted to update you on the latest progress. I can post the code anyway if you would like a peek but you will need a Mac to run it. I haven't given up on this :)

Regards Pär
Group: DynoMotion Message: 9604 From: Tom Kerekes Date: 6/2/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.

Hi Pär,

I just met someone who told me they also had a partial port running on Linux.  The interfaced to the very old KMviaVB interface.  I asked him to check out your posts.  I was hoping the two of you might collaborate.  He was on vacation in California so it may be a while before he gets back to it.

Strange your problem reminds me of years ago running under Wine on Fedora 13 Linux I think I had the same problem.  It connected fine the first time but unplugging the USB and reconnecting it would cause it to no longer communicate properly.   I never resolved that problem but didn't spend very much time on it.   

Please don't give up!

Thanks
TK

Group: DynoMotion Message: 9634 From: par.hansson80 Date: 6/7/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Tom

I have made great progress the last couple of days. I switched out the original ftdi driver in favor of libftdi. This works so much better. On my Ubuntu installation i have to restart the program a few times and then it works flawlessly. But when I unplug and replug the KFLOP i need to restart a few times again. On Raspberry PI however it works just fine. I believe this has something to do with my Ubuntu being a virtual instance and it something somewhere somehow needs to be initialized before it works. Even on MacOSX the new driver gives a smoother ride. Listing devices (RequestedDeviceAvail) is faster with libftdi. 

However I have lost my installation guide document. I need to write a new one and start with a clean installed linux device to make sure all steps are easy to follow. Since I don't have the hardware to install Ubuntu I will use my Raspberry PI for the first release. The guide will most probably work on some other Linux distribution as well. Maybe I can borrow a computer to verify in a non-virtual Ubuntu installation.

I really could use some help with a few things such as interprocess mutexes. So if your acquaintence ever comes back from the vacation I'm all up for some collaboration. Although the rest of the code is almost complete.

Regards Pär
 
Group: DynoMotion Message: 9636 From: Tom Kerekes Date: 6/7/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Pär,

Very interesting and thanks for the update. 

Sorry I can't help wit the interprocess mutexes.  Googling brings up stuff about pthread mutexes.

Thanks
TK

Group: DynoMotion Message: 9992 From: Tom Kerekes Date: 8/17/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Pär,

Did we lose you?  Something we can help with?

Regards
TK

From: "par.hansson@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Saturday, June 7, 2014 2:34 PM
Subject: Re: [DynoMotion] Mac/Linux port of KMotion software and Java binding.

 
Hi Tom

I have made great progress the last couple of days. I switched out the original ftdi driver in favor of libftdi. This works so much better. On my Ubuntu installation i have to restart the program a few times and then it works flawlessly. But when I unplug and replug the KFLOP i need to restart a few times again. On Raspberry PI however it works just fine. I believe this has something to do with my Ubuntu being a virtual instance and it something somewhere somehow needs to be initialized before it works. Even on MacOSX the new driver gives a smoother ride. Listing devices (RequestedDeviceAvail) is faster with libftdi. 

However I have lost my installation guide document. I need to write a new one and start with a clean installed linux device to make sure all steps are easy to follow. Since I don't have the hardware to install Ubuntu I will use my Raspberry PI for the first release. The guide will most probably work on some other Linux distribution as well. Maybe I can borrow a computer to verify in a non-virtual Ubuntu installation.

I really could use some help with a few things such as interprocess mutexes. So if your acquaintence ever comes back from the vacation I'm all up for some collaboration. Although the rest of the code is almost complete.

Regards Pär
 
Group: DynoMotion Message: 10001 From: brad murry Date: 8/18/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hello Pär,

I would be interested in helping with your efforts porting Dynomotion libraries to Linux, let me kowniw if there is anything I can do.

-Brad
From: Tom Kerekes tk@... [DynoMotion]
Sent: ‎8/‎17/‎2014 11:52 AM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Mac/Linux port of KMotion software and Java binding.

 

Hi Pär,

Did we lose you?  Something we can help with?

Regards
TK

From: "par.hansson@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Saturday, June 7, 2014 2:34 PM
Subject: Re: [DynoMotion] Mac/Linux port of KMotion software and Java binding.

 
Hi Tom

I have made great progress the last couple of days. I switched out the original ftdi driver in favor of libftdi. This works so much better. On my Ubuntu installation i have to restart the program a few times and then it works flawlessly. But when I unplug and replug the KFLOP i need to restart a few times again. On Raspberry PI however it works just fine. I believe this has something to do with my Ubuntu being a virtual instance and it something somewhere somehow needs to be initialized before it works. Even on MacOSX the new driver gives a smoother ride. Listing devices (RequestedDeviceAvail) is faster with libftdi. 

However I have lost my installation guide document. I need to write a new one and start with a clean installed linux device to make sure all steps are easy to follow. Since I don't have the hardware to install Ubuntu I will use my Raspberry PI for the first release. The guide will most probably work on some other Linux distribution as well. Maybe I can borrow a computer to verify in a non-virtual Ubuntu installation.

I really could use some help with a few things such as interprocess mutexes. So if your acquaintence ever comes back from the vacation I'm all up for some collaboration. Although the rest of the code is almost complete.

Regards Pär
 
Group: DynoMotion Message: 10002 From: par.hansson80 Date: 8/19/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Sorry about that. I have had 8 weeks off from work on parental leave and vacation. I have not been very active on this, but now I'm back at work. 
As I recall I was almost finished and ready to post the code. I have written new installation instructions since I lost my previous work. I just need a really good disclaimer. I don't want the blame if someone loses a finger, breaks a machine or brick their KFlop due to a coding error. 
Also I'm a bit puzzled about licensing and copyright. For my own sake I don't really care. I just want it to be as free to use as all other code from you guys. And I would be happy if you guys just use it and package it along with the original code. I have tried to make as small changes possible to original code. And it should compile on windows just as before. Although I have not tried the java binding on Windows yet. 
Brad: It would be great with some help. Just to have others actually running the code would be a great help. Also building, packaging and installation scripts for different platforms would help a lot. Currently I have got it to work on both Ubuntu and Rasbian. I have switched to using libftdi instead of ftd2xx driver. Installing the driver with apt-get results in a version named differently. Hence linking against that needs a little bit tweaking. Should be easy to do some auto detection on installed version. 
Best Regards Pär
Group: DynoMotion Message: 10004 From: Tom Kerekes Date: 8/19/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Pär,

That is great news.  You are certainly free to use/copy/modify Dynomotion's disclaimer if that helps.

Looking forward to trying it out.

Thanks!
TK

From: "par.hansson@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Tuesday, August 19, 2014 12:38 AM
Subject: RE: [DynoMotion] Mac/Linux port of KMotion software and Java binding.

 
Sorry about that. I have had 8 weeks off from work on parental leave and vacation. I have not been very active on this, but now I'm back at work. 
As I recall I was almost finished and ready to post the code. I have written new installation instructions since I lost my previous work. I just need a really good disclaimer. I don't want the blame if someone loses a finger, breaks a machine or brick their KFlop due to a coding error. 
Also I'm a bit puzzled about licensing and copyright. For my own sake I don't really care. I just want it to be as free to use as all other code from you guys. And I would be happy if you guys just use it and package it along with the original code. I have tried to make as small changes possible to original code. And it should compile on windows just as before. Although I have not tried the java binding on Windows yet. 
Brad: It would be great with some help. Just to have others actually running the code would be a great help. Also building, packaging and installation scripts for different platforms would help a lot. Currently I have got it to work on both Ubuntu and Rasbian. I have switched to using libftdi instead of ftd2xx driver. Installing the driver with apt-get results in a version named differently. Hence linking against that needs a little bit tweaking. Should be easy to do some auto detection on installed version. 
Best Regards Pär
Group: DynoMotion Message: 10176 From: par.hansson80 Date: 9/15/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Tom

I have posted the code on GitHub. https://github.com/parhansson/KMotionX

I had to move all the code from my previous repository since it was hosted by a friend of mine and his server was bit unstable. The complete package KMotion432 is there since it makes it easier to compare with original source code. If you don't like that i can remove it an only keep the changes there. 

Currently the instructions are a bit messy but you guys are developers as well so you will sort it out. I guess.
I have not tested the code with hardware plugged in for a while since my KFlop is back in my machine and recent changes mostly have been related to build issues on different platform.

 I have made a configure script to detect different versions of installed drivers and Java home etc.

Known issues are:
Java won't build on Ubuntu. (disable with 'configure --disable-java')
I have not tested the new scripts at all on Raspbian (Will do soon)


Brad: 

You are more than welcome to check it out and suggest improvement.

Just take a look att the CMutex implementations and have a good laugh. 



Best Regards Pär

 

 
Group: DynoMotion Message: 10190 From: par.hansson80 Date: 9/19/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hello again.

I have made some improvements to make the code changed less intrusive and tested all install instructions on Ubuntu, Raspbian and Mac OS X. 
Everything seems to work now on all platforms. 

However there are som features missing. Compiling and loading coff files is not tested. Hence you need to flash the configuration and start a thread on boot. At least that is how I have done it for now.

I'm not quite comfortable with executing the load coff methods just yet. Is it possible that I might brick my KFlop by sending faulty data with LoadData command or will the operation just fail?
 
Best Regards Pär
Group: DynoMotion Message: 10191 From: Tom Kerekes Date: 9/19/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Pär!

I wanted to thank you so much for your work.  I looked some of it over and you have a very clean coding style.

I haven't actually got it to work yet but I'm sure that is due to my unfamiliarity with Linux and I haven't had a lot of time to spend on it.  I'm trying Umbuntu 14.04 first.  I'm getting No KMotion devices Available.

I re-programmed the KFLOP USB to remove our Product ID and set it back to the FTDI default.  I wasn't sure what the driver was expecting.  Is there a way to check in Linux what USB devices are connected? Something like Device Manager in Windows?

I get to the point where the app reports:
tk@TKA6:~/git/KMotionX$ sudo cp KMotionX/usb/etc/udev/rules.d/10.kflop.rules /etc/udev/rules.d/
[sudo] password for tk:
tk@TKA6:~/git/KMotionX$ sudo udevadm trigger
tk@TKA6:~/git/KMotionX$ cd bin
tk@TKA6:~/git/KMotionX/bin$ ./KMotionServer &
[1] 4329
tk@TKA6:~/git/KMotionX/bin$ ./executeGCode
bash: ./executeGCode: No such file or directory
tk@TKA6:~/git/KMotionX/bin$ ./ExecuteGCode
Main
Interpreting file /home/tk/git/KMotionX/bin/../GCode Programs/SimpleCircle.ngc
KMotionDLL.cpp:43 Environment KMOTION_BIN resolved to /home/tk/git/KMotionX/bink
KMotionDLL.cpp:59 Environment KMOTION_ROOT resolved to /home/tk/git/KMotionX
Environment KMOTION_ROOT not set, falling back to /home/tk/git/KMotionX/bin
Interpret gcode file.
SocketWrapper.cpp:73 Trying to connect socket /home/tk/git/KMotionX/bin
KmotionIOX.cpp:1053 ErrorMessageBox: No KMotion devices available
AfxMessageBox: No KMotion devices available OPTION: 331792
AfxMessageBox: Can't Connect to KMotion Board #0 OPTION: 331792
CALLBACK Complete -- status: 1005 line: 0  error: Unable to read defined coordinate system axis positions
Error in line 0
Unable to read defined coordinate system axis positions
tk@TKA6:~/git/KMotionX/bin$


Regarding "bricking" KFLOP.  That should be very unlikely.  If memory is corrupted you should be able to simply cycle power and re-boot KFLOP.  If the current Version's Flash or a Flashed User Program is corrupted preventing boot there is a Flash Recovery Option on the Config/Flash Screen to Restore it.

I believe we promised 4 Dynomotion Boards for some effort on this and this is more than we expected.  PM me or send a note to Dynomotion Support which boards you would like and where to send them.

Thanks!
TK

From: "par.hansson@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Friday, September 19, 2014 3:02 PM
Subject: [DynoMotion] Re: Mac/Linux port of KMotion software and Java binding.

 
Hello again.

I have made some improvements to make the code changed less intrusive and tested all install instructions on Ubuntu, Raspbian and Mac OS X. 
Everything seems to work now on all platforms. 

However there are som features missing. Compiling and loading coff files is not tested. Hence you need to flash the configuration and start a thread on boot. At least that is how I have done it for now.

I'm not quite comfortable with executing the load coff methods just yet. Is it possible that I might brick my KFlop by sending faulty data with LoadData command or will the operation just fail?
 
Best Regards Pär
Group: DynoMotion Message: 10192 From: alexmstahl@rocketmail.com Date: 9/20/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi, a raspbian port of kmotioncnc would be great! I'd be more than happy to help test it when the time is right. thanks, Alex
Group: DynoMotion Message: 10193 From: par.hansson80 Date: 9/21/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.

Hi Tom

Thank you it feels good that my efforts are appreciated. I have tried my best to make 
understandable code and not do diverge from current style. Since I mainly code in Java 
I don't have very much experience from C++ projects in this size. I only use C and C++ for
very small programs. 

In the libftdi API it is possible to set product and vendor Id before listing usb devices.
I have used the KFlop vendor and product Id in the code so you should reprogram it back to 0403:f231
I get the exact same error if I run the gcode example without plugging it in.

Next problem that might occur is that you might get a message saying "Operation not permitted"
or similiar. That is what the /etc/udev/rules.d/10.kflop.rules is supposed to solve. It creates
a rule to grant a user belonging to group "users" permission to write to any USB device with 
vendor and product IDs set to 0403 and f231.
This rule works as expected on Rasbian but not Ubuntu. Users on Ubuntu does not neccessarily belong to
a group named "users" and that might be the problem.
It just happened to work when "udevadm trigger" is executed so I left it that way for now.
I need to fix that rule for Ubuntu later on.

If you would like to see wich usb devices that are mounted and attached to the device 
file system(linux uses file system abstractions for lots of things and this is one of them) 
you can usb the command lsusb

To see specifikt devices use vendor and optionally product id with -d option 'lsusb -d vendor:[product]'

for KFlops that will be

lsusb -d 0403:f231

and the answer should be something like this

Bus 003 Device 005: ID 0403:f231 Dynomotion, Inc. KFLop

then you know where to look for your board in the device(dev) file system

ls -la /dev/bus/usb/003/005

where 003 is the bus and 005 is device id on your system. Bus and device id might change every 
time you reconnect the device. The answer might be something like this.

crw-rw-r-- 1 root users 189, 130 Sep 17 06:56 /dev/bus/usb/003/005

Here you can see the permissions granted for user on this device(if you now how interpret this)
crw-rw-r-- is three groups of rwx grants (read write and execute). The groups are in order
of owner, groups and everyone else. So root have both read and write permissons. Users in
group "users" has read and write. Everyone else has only read permissions.

This will most likely be fixed by the 'udevadm trigger' command, resulting in write permissions as well
crw-rw-rw- 1 root users 189, 130 Sep 17 06:56 /dev/bus/usb/003/005


BTW. I can see that you are not using the latest code
since you got this error. bash: ./executeGCode: No such file or directory

You should rebuild on the latest code. 
cd ~/git/KMotionX
git pull
make clean && make all
Group: DynoMotion Message: 10225 From: par.hansson80 Date: 9/28/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Alex

I agree, that would be great. That will be a future project though. I just got my 40w laser engraver I ordered on ebay and just as expected the software and hardware is not meeting my demands. 

My current project is to use a KFlop as controller and a Raspberry Pi running LasaurApp. That way I get a chance to test and debug the Linux port on a less expensive hardware than my mill. 

If no one else makes a KMotionCNC port before me you are more than welcome to help.

/Pär
Group: DynoMotion Message: 10544 From: par.hansson80 Date: 11/22/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi everyone.

I have now implemented a HTML5 GUI that works with the linux port of KMotion software.
It is currently not a fully functional replacement of KMotionCNC. Also the layout is not anywhere final.
I like to think of it as a demo of what can and will be done in forthcoming updates.

I currently use it to control my 40W laser. Hence I'm focusing my work on whatever features I need for that. But will use it on my three axis milll later on. I guess i need to buy myself a lathe to fulfill everyones needs :)

There is currently no documentation how to use it. But I'm aiming at making it easy enough to understand if you are using the KMotionCNC today.

Some features:
WebGL 3d view of code.
Drop gcode files or svg files in window.
Open same application on different(or same) hardware(pc tablet etc) and they will be synched.
Simulation mode.

Party implemented features:
Support for several machine configurations.

To be implemented:
User buttons and M codes.

I have only tested it on Mac and it passes quality control with "Works on my machine" stamp.


/Regards Pär
Group: DynoMotion Message: 10545 From: ericncn Date: 11/23/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Pär,

I will try to install your software on an Ubuntu machine I have here (if it can work in simulation mode without a KFlop attached).
If it works I'll then try to install Ubuntu on the machine controller. If I could finally get rid of WIndows I'd be more than happy.

I'm very interested i what you're doing,
keep up the good work!

EC

---In DynoMotion@yahoogroups.com, <par.hansson@...> wrote :

Hi everyone.

I have now implemented a HTML5 GUI that works with the linux port of KMotion software.
It is currently not a fully functional replacement of KMotionCNC. Also the layout is not anywhere final.
I like to think of it as a demo of what can and will be done in forthcoming updates.

I currently use it to control my 40W laser. Hence I'm focusing my work on whatever features I need for that. But will use it on my three axis milll later on. I guess i need to buy myself a lathe to fulfill everyones needs :)

There is currently no documentation how to use it. But I'm aiming at making it easy enough to understand if you are using the KMotionCNC today.

Some features:
WebGL 3d view of code.
Drop gcode files or svg files in window.
Open same application on different(or same) hardware(pc tablet etc) and they will be synched.
Simulation mode.

Party implemented features:
Support for several machine configurations.

To be implemented:
User buttons and M codes.

I have only tested it on Mac and it passes quality control with "Works on my machine" stamp.


/Regards Pär
Group: DynoMotion Message: 10547 From: ericncn Date: 11/23/2014
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Pär,

I have tried to install your software on a Ubuntu 12.04.5 computer (NOT connected to a KFlop).  I did apt-get clean all ; apt-get update ; apt-get dist-upgrade just before attempting the installaiton so I have all the latest versions of each package in the system.

I have found these problems:

- couldn't even start compiling because the -std=c++11 flag is unknown to my gcc version

- I replacd the -std=c++11 option in the include.mk file with, alternatively, c++98, gnu++98, gnu++0x, c++0x  all with similar results:
it compiled a few files then got stuck in CMutex2.cpp because the way the variable Ms is (not) declared

- I removed all the offending lines containing Ms in CMutex2.cpp, next errors happened in handler.cpp, again I removed all the offending lines, then I finally reached the end of the compilation

If you could try replace c++11 with c++0x in your include.mk, you would probably see the same errors I'm getting.


- then I went to KMotionX/tcc-0.9.26 and tried to build the Tiny C Compiler.

I got errors because texi2html and texinfo were missing in my system

(I suggest you correct your instructions stating that's only for Raspbian users, actually all users need to install texi2html and texinfo)

- once I did that, I could compile the Tiny C Compiler and finally launch the web server and the web application!  :-)


Thank you again for the good work
EC
Group: DynoMotion Message: 10771 From: juanitocincovivo Date: 1/4/2015
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hello Pär,

What's the status on this port?

Specifically-

What is the library coverage? (is there near complete parity)

If so, it would be great to integrate the two versions and have a truly cross-platform code base. (Not sure what TK's stance on that might be)

-Brad Murry
Group: DynoMotion Message: 11005 From: mean_taipan Date: 2/2/2015
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Pär,

Thanks for the trendous effort you put into this.  I only hope you're still motivated.

On Ubuntu 12.04 (x86_64), the code builds ok (without Java and with libftdi), although as EC pointed out previously, I had to change to -std=c++0x since the g++ compiler is version 4.6 (not 4.7).  I don't think it really uses much of anything from the c++11 standard.  The two changes made to the code, to make it c++0x, were very trivial.

The web application puts some windows over others, at least in Firefox 34.0, so I couldn't use it.  Not sure if it's even connecting to the Kflop.

kflopConsole seems to work, although if a script command does not send any response then it times out after a few seconds and prints "Command failed".  For example, 'version' works fine, but 'clearbit47' prints an error, although the command itself seems to work because the LED on the Kflop turns off as expected.

My interest in this is that I would like to get this working on the Beaglebone Black (runs Debian/Ubuntu), mainly so we can provide Ethernet connectivity and a simple GUI console on our machine.  We'll probably try for a Python binding, so we can write the app using GTK+3 Python binding.  Failing that, we'll try the FOX GUI toolkit.

The HTML5 app looks really cool, and would give us our Ethernet connectivity, but I don't know anything about it so I would rely on others for that.

Regards,
AB
Group: DynoMotion Message: 11006 From: Dan W Date: 2/2/2015
Subject: Re: Mac/Linux port of KMotion software and Java binding.
AB,
Another platform to look at might be the just released Raspberry PI B 2.0. It just came out in the last couple days. 900 mhz cpu with 1 gig of ram. Microsoft is working on a free version of Win 10 for it too. 

Dan


Group: DynoMotion Message: 11024 From: Hardy Family Date: 2/4/2015
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi Dan,
I had a look at the new R. Pi and it looks very interesting.  I'm not quite up to working with it or the Beaglebone yet; still getting it to work reliably on the Ubuntu Laptop.  But it's on my to-do list.

Tom:
I have made some progress with the Linux port.  A few little bug fixes, including making the CheckCoffSize() API behave sanely when there is no debugging information.  TCC does not work with the -g option (it gets a buffer overflow error).  I am, however, able to load and run C code on the Kflop, with one limitation which I have discovered so far, which you might be able to help me with.

The problem is that printf() seems to be sending garbage (or nothing) back to the console.  If I use a coff file created by KMotion (running under Wine) it all works fine, but programs compiled on native Linux don't do printf's properly.  They do seem to work otherwise, since I can flash LEDs and the like.

If I run the Linux coff file, there is no console output.  If I then run the Wine version, the console prefixes the proper message with some garbage bytes (seems consistent), and thereafer the Wine version works normally.  So it looks like there is some garbage data in the pipe which is not properly terminated with a LF, and only when a properly formatted message is sent does the console callback get invoked.  (Do printf's always need a NL terminator?  Or do unterminated lines get sent to the host PC as soon as available?  Are unterminated lines buffered in the PC side until terminated?)  Note that so far only one program (a simple printf("Hello World!\n") actually generates garbage data; everything else I have tried does not seem to output anything.

I suspected that the string constant in the printf was not getting its address properly linked, so then I tried using a char array (on the stack) that was set up one-by-one.  Same deal.

Maybe this version of tcc is setting up varargs differently than expected.  Unfortunately there does not seem to be a puts() so I can't test this theory.

I'm thinking of doing some debugging via setting persist variables (which I can then interrogate using GetPersistXXX commands).  Is there a better way?

Anyway, apart from that I have a basic Python binding to the DLL, which is handy for testing.  The binding is generated using swig.  More on that once it is a bit more robust.

Regards,
AB


On Mon, Feb 2, 2015 at 8:13 PM, Dan W engnerdan@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

AB,

Another platform to look at might be the just released Raspberry PI B 2.0. It just came out in the last couple days. 900 mhz cpu with 1 gig of ram. Microsoft is working on a free version of Win 10 for it too. 

Dan


Group: DynoMotion Message: 11038 From: par.hansson80 Date: 2/7/2015
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi EC

Sorry about not answering before. 
I have only tested it on Ubuntu 14. I believe there is a comment about gcc-version in the readme stating at least gcc-4.7.

I added the c++11 dependency because I had to use the recursive_timed_mutex
The problems I had at the moment stopped and I left it there. Both the CMutex and CMutex2
is kind of experimental code.

I will try to make the changes sometime. But it is not the highest priority right now. I'm currently working on the HTML5 application.

But you are right I should update the documentation. Thank you for finding the errors. I have no time to test all platforms from scratch for every commit. 

Pär
Group: DynoMotion Message: 11039 From: Hardy Family Date: 2/7/2015
Subject: Re: Mac/Linux port of KMotion software and Java binding.
I have done a few fixes to the code.  It compiles and runs with c++0x, since I'm working from Ubuntu 12.04 and couldn't be bothered upgrading g++.  Also fixed a server crash with ListLocations().

If you like, I could put in a pull request for the github repo.  I've made a new branch called 'swig' (for the Python binding), but it includes some other stuff including the ability to use TCP/IP sockets (had to change the client-server protocol slightly for this to work reliably).

Regards,
AB


On Sat, Feb 7, 2015 at 2:49 PM, par.hansson@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi EC


Sorry about not answering before. 
I have only tested it on Ubuntu 14. I believe there is a comment about gcc-version in the readme stating at least gcc-4.7.

I added the c++11 dependency because I had to use the recursive_timed_mutex
The problems I had at the moment stopped and I left it there. Both the CMutex and CMutex2
is kind of experimental code.

I will try to make the changes sometime. But it is not the highest priority right now. I'm currently working on the HTML5 application.

But you are right I should update the documentation. Thank you for finding the errors. I have no time to test all platforms from scratch for every commit. 

Pär
Group: DynoMotion Message: 11040 From: par.hansson80 Date: 2/7/2015
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Hi again. 

Brad:
The status library coverage is near complete. I have not tried every single function. Uploading off files is not tested very much. As AB says there seems to be a problem with the compiled coffs. The problem seems to be the compiler but not the library code. I just couldn't get the shipped TCC version compile. So I naively used the latest and believed it would work. But I had to do lots of patches by comparing code and binaries. These patches should be committed to the original tcc source. Since C67 output is broken in their version. I haven't done that either. Obviously I have not got it all right.
I have tried to make as small impact as possible to the original source. And it should compile on Windows as well. Although I have removed all CStrings which is quite the opposite to what I just said. However I think the code would be better without it anyway :) 

AB:
I'm still motivated. I just don't have time to work on this continuously. The Beaglebone is an interesting platform as well. I don't have one myself. But the new Raspberry Pi is comparable in performance i guess. 

I too have experienced some garbage data when I was testing console prints but i thought I was doing something wrong. 

Pär
Group: DynoMotion Message: 11041 From: par.hansson80 Date: 2/7/2015
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Great.

Create a pull request. At least I can have a look at the code and do a manual merge. 

Regards
Pär
Group: DynoMotion Message: 11043 From: Hardy Family Date: 2/7/2015
Subject: Re: Mac/Linux port of KMotion software and Java binding.
OK, done that (my github user ID is meantaipan).

Note that for the client-server protocol, I had to add a length prefix to most messages (except the single-byte ACK).  This is because, with a stream socket, packets can be arbitrarily broken, and there is no indication of packet boundaries.  Although the old code happens to work with unix domain sockets, that is more a matter of luck.  TCP over a real network would definitely cause problems.  The other main change to the KMotionServer code is that it now listens on a unix- and tcp-domain socket using the select() system call.  On the client side, there is an alternative constructor to tell it to use tcp with a given hostname and port.

My main motivation for TCP is because we want to be able to use Ethernet rather than USB to connect to our new machine.  Of course, we won't be able to use all the KMotion-CNC etc. windows software as yet, but we should be able to tweak the server to use winsock.

The Python binding is incomplete.  At present, I am working on making the "main status" information available to Python code.  See python/test.py for an example.

Regards,
AB


On Sat, Feb 7, 2015 at 3:26 PM, par.hansson@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Great.


Create a pull request. At least I can have a look at the code and do a manual merge. 

Regards
Pär
Group: DynoMotion Message: 11054 From: Hardy Family Date: 2/9/2015
Subject: Re: Mac/Linux port of KMotion software and Java binding.
The original TCC67 compiler now compiles on Linux, tested on Ubuntu 12.04 (64 bit) with gcc4.6.  It generates the exact same binary code as the Windows version of TCC67, at least with the usual KMotion options (-g -nostdinc etc.).  It also works the same without -g.

You can check out the changes at
https://github.com/meantaipan/KMotionX
(swig branch).

Most of the changes were related to 64-bit vs. 32 bit.  The original code wanted to cast back and forth between pointers and 'int', so I had to put in a bit of a hack to get around this.

Enjoy,
AB
Group: DynoMotion Message: 11469 From: vjbaskar1986 Date: 5/4/2015
Subject: Re: Mac/Linux port of KMotion software and Java binding.
Dear Par Hansson,

I am using Raspberry Pi2 to compile your KMotionX software. Unfortunately i am experiencing compilation during "make"
My errors are as follows:-

Softwares/git/KMotionX/GCodeInterpreter -D_KMOTIONX -DLIB_FTDI
handler.cpp -o build/handler.o
handler.cpp:68:22: sorry, unimplemented: non-static data member initializers
handler.cpp:68:22: error: ISO C++ forbids in-class initialization of
non-const static member ‘interpreting’
handler.cpp:69:19: sorry, unimplemented: non-static data member initializers
handler.cpp:69:19: error: ISO C++ forbids in-class initialization of
non-const static member ‘last_line’
handler.cpp: In function ‘void handleUploadRequest(mg_connection*)’:
handler.cpp:597:23: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
/home/pi/Softwares/git/KMotionX/include.mk:38: recipe for target
'build/handler.o' failed
make[1]: *** [build/handler.o] Error 1
make[1]: Leaving directory
'/home/pi/Softwares/git/KMotionX/KMotionX/examples/webgui'
makefile:22: recipe for target 'subdirs' failed
make: *** [subdirs] Error 1

Please advice.

thank you